Skip to main content

BTG Id

Authentication​

The services provided by the BTG Pactual Empresas APIs require the partner application to go through one or more of the authorization flows. In this section you will get an overview of the basics of how our BTG Id authentication server works.
Pay attention to the following sections to learn the use of each of the flows.

BTG ID​

BTG Id is the BTG Pactual Empresas authentication and authorization platform, and it is through it that partners are granted access to our APIs.

We operate with a permission system at the user level, ensuring that no system can access data without first obtaining the permission of the user whose data will be accessed.

BTG Id follows the OpenID Connect and OAuth 2.0 protocols, allowing the use of open source libraries in the developer's preferred language or platform.

Basic concepts​

This is the standard flow for using our APIs, and we can see that there are four parties involved:

  1. Authorization Server:
    The authorization server is the module responsible for guaranteeing the user's identity, granting and revoking access to certain resources, and issuing tokens. The tokens come to you in two types: the Access Token and the Refresh Token.

    • Access Token: The token issued based on the permissions granted by the end user. It represents the application's authorization to access certain user data in the API. It has a 24h duration.
    • Refresh Token: The token issued together with the Access Token and used to renew it without the need for interaction with the end user. It has a 10-day duration (RENEWABLE).

    An example of an Authorization Server response containing the Access Token and the Refresh Token:

   {
"access_token":"eyJhbGciOiJSUzI1NiIsInR",
"refresh_token":"WV6G4HKBrv",
"scope":"apps email openid profile webhooks",
"id_token":"eyJhbGciOiJIUzI1NiJ9.eyJzd",
"token_type":"Bearer",
"expires_in":86400
}
  1. Resource Owner
    Usually also the end user, the Resource Owner is the holder of the data to be accessed and is the one who grants access to certain resources to the Client.

  2. Client
    This is the partner application, identified by the Client Id, and it is the part of the flow that requests tokens from the Authorization Server, based on the Resource Owner's permissions.

  3. Resource Server:
    This is the part of the flow where the Resource Owner's data is located, and this is where the Client is securely authenticated and access to the data is granted through the Access Token.